The disclosed embodiments relate to playing multimedia contents stored on an optical storage medium, and more particularly, to optical storage medium playback apparatuses which use an external storage connected thereto for buffering data read from an optical storage medium or providing a playback schedule of data on the optical storage medium, and a related method thereof.
Some multimedia contents are contained within data files. In general, a container defines its content's file format. Specifically, a container format is a file format whose specification regards only the way data are stored within the file, whereas no specific coding scheme of the data is implied or specified. For example, MPEG-4 Part 14, formally ISO/IEC 14496-14, is a multimedia container format standard which is specified as a part of MPEG-4. It is most commonly used to store digital audio and digital video streams, especially those defined by MPEG, but can also be used to store other data such as subtitles and still images. As the official filename extension for MPEG-4 Part 14 files is .mp4, the container format is often referred to as MP4. As known to those skilled in the art, the MP4 file includes a first part including header information of the multimedia content, a second part including multimedia content's audio/video data, and a third part including tables which record file offsets (file positions) of the audio/video data for normal-mode playback or trick-mode playback (e.g., fast forward, fast reward, time search, etc.). Note that an audio/video stream from an MP4 file is divided into a number of data chunks. Moreover, those audio chunks and video chunks are interleaved evenly in the second part of the MP4 file for smooth playback. In MP4 format, only tables in the third part contain the file offsets of data chunks. Without these tables in the third part, it is impossible or difficult to identify the start/end file offset of a data chunk, where an end offset of one data chuck is a start offset of the next data chunk. Therefore, these tables are necessary for normal-mode/trick-mode playback of an MP4 file since fast forward/reward and time-search operations need to seek the start file offsets of some corresponding data chunks. Preferably, all of the tables should be loaded from the MP4 file into a memory before the actual playback starts. However, regarding a conventional optical disc player generally having limited resource due to cost considerations, such an implementation is not feasible as the optical disc player does not have enough memory to buffer all of the tables included in the MP4 file. Instead, the conventional optical disc player loads the requested tables on demand. That is, the conventional optical disc player first moves an optical pick-up head to seek tables of the MP4 file recorded on an optical disc, and then loads a portion of the tables included in the MP4 file into a small-sized internal memory, say, a dynamic random access memory (DRAM) with a maximum capacity of 2 megabytes for acting as a frame buffer, a video-audio streaming buffer, etc. This is because it is very common that the total size of tables from the third part of an MP4 file is larger than 2M bytes. Next, the conventional optical disc player moves the optical pick-up head to access requested audio/video data chunks for playback according to tables loaded into the internal memory. As only a portion of all tables included in the MP4 file is loaded and the access of the audio/video data chunks relies on the file offsets (file positions) pointed out by information stored in the tables, the amount of audio/video data chunks allowed to be played is therefore limited. When the file offsets (file positions) of following audio/video data chunks to be played are not available from the currently loaded tables in the internal memory, the conventional optical disc player has to move the optical pick-up head to seek needed tables of the MP4 file recorded on the optical disc, and then loads another portion of all tables included in the MP4 file into the internal memory. However, seeking data recorded on an optical disc is quite time-consuming. Besides, seeking from the second part of an MP4 file to the third part thereof and then moving the optical pick-up head back to the second part may consume at most 2 seconds for conventional optical disc players. In these 2 seconds, no audio/video data is parsed into the audio/video buffer, meaning that the audio/video buffer should be large enough for storing audio/video data required by playback for at least 2 seconds to thereby prevent any playback lag (buffer under-run). It is, however, difficult for a 2M-DRAM optical disc player to satisfy this requirement.
Regarding playback of files complying with other file formats, the conventional optical disc player still suffers from the small-sized internal memory. Taking the RealMedia (RM) format for example, the audio data included in an RM file are interleaved, which means that the audio data have an interleaved storage order different from an actual playback order thereof. Therefore, to smoothly play the multimedia content of the RM file, some of the interleaved audio data sequentially read from an optical disc should be stored in a buffer memory before they are played according to the actual playback order. However, in a case where the conventional optical disc player is not equipped with enough buffer memory space, the optical pick-up head must perform some unavoidable seeking operations, degrading user experience significantly due to audio/video lags.
With regard to the Audio Video Interleave (AVI) format, the tables stored in an AVI file are only used for trick-mode playback operation. However, as the conventional optical disc player does not have enough memory to buffer all of the tables included in the AVI file, the conventional optical disc player samples the tables included in the AVI file to select part of the tables to be loaded into the small-sized internal memory. As the internal memory merely stores a simplified version of tables, the conventional optical disc player fails to perform the trick-mode playback operations accurately. For instance, in each AVI file, there is a table which stores tuples (time, file-offset) for performing trick-mode operations. AVI file X may has tuples (0:30:00, 0x5000), (0:30:30, 0x6000), (0:31:00, 0x7000) in its table T. Since the size of the available memory is limited, the conventional optical disc player can only extract a sampled table S from table T to the memory. Table S may contain only (0:30:00, 0x5000), (0:31:00, 0x7000) after sampling. As a result, when a user performs a time-search action to time 0:30:30, the conventional optical disc player may only start displaying pictures from time 0:30:00 or 0:31:00. Such trick-mode operations are inaccurate.
In addition, an end user basically uses the remote control to control the conventional optical disc player. However, it is very inconvenient when the control is complicated. For example, the end user may want to show some pictures (still images) on a display device. The end user therefore has to arrange the display order and display timing for these pictures. In addition, the end user may also want to have background music played during the slideshow of the pictures. However, the conventional optical disc player does not have enough memory space available for recording all of the presentation timings for the image files and audio files. Besides, the end user may feel uncomfortable to do such playback scheduling by performing a lot of button-pressing actions on the remote control.
Therefore, it is desired to improve the user experience and the user-interface control convenience for a resource-limited optical disc player, such as a low-memory optical disc player.